Continuus Software Corporation, October 26, 1995
1.0 Background
2.0 Atria Message and Response
Recently, Atria sales staff began distributing Atria-prepared "Competitive Evaluation" email messages comparing ClearCase with Continuus/CM (C/CM). The messages include descriptions of C/CM capabilities and architecture, many of which are inaccurate. In this document, we include the full and complete text of the Atria messages, along with our corrections, and answers to the questions posed.
The interested evaluator is encouraged to obtain one of the independently produced competitive evaluations for an objective, unbiased comparison:
Each of these reviews points out the strengths and weaknesses of both products. Certainly, no product is perfect -- including C/CM -- and no product can be optimized for the needs of all customers, but we hope evaluators take the time to investigate and draw their own conclusions.
Since many of the misrepresentations of the C/CM product are well documented in external papers, product documentation and published data models, we believe Atria's misrepresentations were intentional.
Note: Paragraphs in italics are from the message text distributed by Atria.
1) Version Control EngineContinuus is layered on SCCS or RCS. It achieves transparency by constructing a sandbox consisting of links and private copies when checked out. Because of the lack of tight integration with a version-control engine, Continuus uses the engine in a generic way that is inefficient.
An API exists to plug in any version control tool. SCCS/RCS store archived versions, transparently to the user. A version is archived when it is promoted to a static state. Cache directories store a physical copy of all active versions referenced by a project. A utility (clean_cache) can purge static versions from cache area, but must be explicitely invoked.
C/CM uses the underlying SCCS engine with remarkable inefficiency. Instead of using the native SCCS support of branches, C/CM adds each new file version to the head of the SCCS trunk, regardless of the derivation history of the mew version. This grows increasingly inefficient as old and new branches diverge.
A simple idealized benchmark was run. A 1000-line file was created and branched, then all 1000 lines on the branch were changed to simulate old and new development lines. Then several small changes were made, alternating between the main trunk and the branch.
Using SCCS directly, the final archive had 2083 lines. The same changes entered using C/CM resulted in an archive with 6088 lines.
+ ClearCase has created a virtual file system. All versions of all files are on line and can be accessed at any time by normal unix utilities. A user can gain access to a specific related set of versions in a matter of seconds.
Q: How long does it take to construct a new sandbox for a file structure consisting of thousands of files? What steps are necessary to do this?
What is required is: define project, tailor visible part of selection rules, reconfigure, and synchronize.
Continuus responds: The root of Atria's misrepresentation regarding C/CM's version management system is the claim that C/CM uses SCCS or RCS as its version management engine. This is false, as shown below. Furthermore, Atria has a complete misunderstanding of the C/CM branching implementation and functionality. The response to the claims about the differences in branching will be deferred to the Branching discussion below.
Continuus contains its own version management system, comprised of over 200,000 lines of Continuus proprietary code. We absolutely allow the use of RCS, SCCS, or PVCS (or other tools) as the underlying archiver. The only responsibility of the archiver is to reliably store and retrieve specific revisions that are no longer being modified. As Atria well knows, neither SCCS nor RCS has the underlying power necessary as a version control system to support the parallel development methodologies that today's large software teams require.
The fact that we allow customers to plug in an archiver of their choice is a feature that, when used as designed on a type-by-type basis, allows different object types to be archived using a tool optimized for that particular type. This is why, out-of-the-box, the C/CM product uses different archivers for text and binary objects, and why different types with structured binary object representations (such as FrameMaker documents, or PowerBuilder libraries) can use archivers with specific knowledge of the object type being managed.
C/CM most definitely maintains a cache of clear text files for those versions currently being utilized. According to Atria documentation, ClearCase does the same thing. This cache is garbage collected through a very simple administration operation, typically set up to run nightly. The difference is that with C/CM, once a version is in the cache, access to that file version is instant, versus the delay experienced by ClearCase users due to having to go through their proprietary file system layer.
More generally, we believe an important limitation of the ClearCase focus on files, which is forced by a file-system-based approach, is that many of the advanced development environments, especially in the Windows world, are not oriented around files, but are much more object-based than what ClearCase supports. In contrast, the C/CM version control engine was designed around a core object system which supports both file and non-file based object types.
Finally, the upcoming 4.1 release of C/CM (currently in Beta test) does not require the synchronize operation any longer; this is now a transparent operation.
2) Network LimitationsA Continuus repository, while it is scalable across a network, is isolated from all other repositories. An object that needs to be reused in a second repository is a separate object with its own history.
A Continuus repository can be distributed on any number of file servers. The metadata (Informix) portion can be on a separate machine. The Informix server does not need to have Continuus installed and can be yet another machine. Source, cache, archives, and objects can be distributed anywhere on the network.
+ The ClearCase repositories (VOBs) can be spread across any machine in the network that supports NFS. The database portion must reside on machines where ClearCase software is loaded. The source, object, and cache pools can be located anywhere.
This network of repositories can be linked as one hierarchical disk structure or seperated into as many substructures as desired. A project can make use of any or all of the data as necessary. Code can be common to everyone or restricted to a subset of users.
There are no limits to the number of files or number of versions in any one VOB. Network access, memory, disk allocation, CPUs, and logical groupings will determine how you should best distribute your software.
Q: I have two separate applications (and development groups) that share common code. Their applications are stored in separate repositories for administrative reasons of separate servers and cost centers. How do I share code between the two applications?
Continuus responds: Virtually every C/CM customer uses data from multiple C/CM repositories. Contrary to the claims above, data from multiple repositories can be projected into one or more hierarchical disk structures, very much like ClearCase. Furthermore, Continuus licensing allows any user to access any number of repositories simultaneously.
There is, however, one very significant difference between the two underlying technologies that does have an impact on the degree to which multiple repository environments are used. Atria is implemented on top of a proprietary DBMS, based on DB-VISTA source code licensed from RAIMA Corporation.
Atria chose not to implement ClearCase on top of a highly scalable, high performance commercial DBMS such as Oracle, Sybase or INFORMIX. While this decision did save Atria a significant amount of money, the consequence for their users is that the size of ClearCase VOB's is severely constrained. Unlike the claim above that there are no real limits, Atria's own documentation recommends keeping the repositories very small for performance reasons (only 2500 objects and 20 users for a high-end system with 64 MB RAM, 2 GB disk and 20-35 MIPS). So, a user of ClearCase with a code base of any real size is forced to set up and administer artificial clusters of VOB's.
In contrast, the C/CM product is based on INFORMIX which scales to extremely large repositories. So even very large project teams with large code bases are able to operate with a small number of repositories, which can have significant administration and process support advantages.
Another advantage of the C/CM repository architecture is that C/CM with INFORMIX supports non-stop operation, which means that project databases can be backed up on-line, administered on-line, and even if the machine running the database server is brought down, the project files remain accessible. Contrast this with ClearCase's file-system based implementation which makes the files inaccessible if the machine hosting the files goes down. Given that a reboot is required to apply each of the many ClearCase patches to their proprietary file system, this can be quite frequent.
We believe that the lack of a serious embedded database is the underlying reason for the performance problems experienced by ClearCase users with nontrivial amounts of data (see the Ovum evaluation for a discussion of these performance problems reported by ClearCase customers). Furthermore, because Atria has significantly modified the source code to their purchased DB-VISTA database, they are forced to spend a substantial percentage of their time and resources trying to keep up with basic database technology, rather than leveraging the literally millions of lines of software and hundreds of developers that go into any one of the major databases. Continuus and our customers are able to leverage the ongoing innovations in database technology including support for SMP servers, parallel queries, and replication services. Besides the ongoing improvements to the underlying database technology, this allows Continuus development staff to focus resources on the application which is modern software configuration and change management, which we believe explains why Atria has been so shallow in process and change management functionality when compared with Continuus.
A final point about architecture is that Continuus believes that while there are benefits to file-system-based SCM systems, the development environments of today are composed of systems which do not all support alternative file systems (e.g. Windows 95, Windows for Workgroups, MacOS). For these systems, Atria is forced to provide a very shallow and inconsistent solution of a front-end (Atria's Attache), rather than the capabilities of the full product. In contrast, the full set of services of C/CM, with a consistent user interface and operation, is available across all of Continuus' supported platforms and operating systems.
3) BranchingContinuus branches are not first-class objects in the database, but are represented by attaching text attributes to the object versions; this can make searching for parallel versions and notifying the user of their existence impractical for performance reasons. The history about branching points and the ancestory of any particular version can be modified by an end user.
+ ClearCase branches are an integral and powerful part of our version-control solution. Branches are named and typed objects. The history embodied in a branch is protected as strongly as any other object in a VOB. Branching is easy and automatic. Files are branched as needed. ClearCase automatically computes a common ancestor of multiple lines of descent, a crucial feature for any advanced merge capability.
Q: When a developer needs to create a new version to fix a defect, how does s/he knows where to branch from?
Q: If multiple branches of a file are active, how does Continuus determine which branch to incorporate in a view?
Continuus responds: Atria's description of the Continuus branching support is nearly completely inaccurate. Their misconceptions appear to stem from their belief that branches are implemented as attributes. In fact, independent of the C/CM attribute system, the C/CM data model has three types of relationships, each implemented as first-class objects, right down to the DB schema level. The three types of relationships are derivation (foundation for branching), binding (membership in projects/configurations) and hypertext (associations between arbitrary objects). Given that Continuus actually publishes the C/CM schema, we see little excuse for such misrepresentation.
So branches, and the derivation relationship in general, are most definitely first-class objects, and in fact there is built-in support for queries on these objects (e.g. is_predecessor_of, has_predecessor, etc.). Moreover, this is critical to implementing intelligent merge based on the derivation history (which again, Atria incorrectly claims C/CM does not support).
Regarding the claim that any user can modify the branching and derivation relationships, this is also untrue. Once an object has been checked in, it can no longer be modified, nor can its derivation relationships. Our built-in security (which is considerably more comprehensive than ClearCase) covers this. The only exception to this is that the systems administrator role (analogous to superuser) does have the ability to make changes.
Regarding the claim that ClearCase has somehow more automatic and easy to use branching, with C/CM the user simply indicates the branch he is working on through a single choice on a pop-up dialog, and all changes are automatically associated with that branch.
Regarding computing the common ancestor, the Atria claim that we do not do this is once again false. In C/CM, the derivation and branching history is analyzed to return the nearest common ancestor, just as is done with ClearCase.
Based on our analysis, both C/CM and ClearCase support full branching capability. There are differences in usage, but both products support an arbitrary number and type of branches, and provide branch-based version selection, work area definition, merge and build.
Finally, Atria seems to be implying that the use of attributes in general is somehow deficient. Unlike ClearCase, C/CM implements attributes as first-class objects, which are themselves typed, and can store either data or methods. Attributes are very important and are used extensively to provide metadata for variant support and for change management in particular.
4) MergingContinuus uses Atherton's MergeAhead tool, old and weak technology. MergeAhead can only merge two versions at a time, and it only operates on individual files, not entire directories or projects. For these reasons it can be very difficult to accomplish complicated merges and it is impossible to automate them.
+ ClearCase has the most sophisticated merge capabilities available today. You can find and merge from any related set of branches to any target set of branches in one command. Any changes that do not conflict can be merged automaticly or manually reviewed as desired. Changes introduced in the past can be merged out automatically. Changes from any single version or any range of versions can be isolated and merged into other lines of descent.
Q: Can I choose multiple branches of descent, find the common ancestor for all of the branches, use it to determine the deltas of the latest versions on those branches, and in one step merge the results into any branch I choose?
Q: Can I do this in a mode where only conflicting changes across the entire version set are presented for resolution?
C/CM can do this when doing incremental "imports" (Vendor Code Management, Distributed Code Management), not when looking at versions created in the repository.
Q: Can I change my mind interactively and monitor all changes but still know which ones are conflicting?
Q: Can I find in one step all the files from a branch or set of branches that have not yet been merged to a branch of my choosing?
Continuus responds: In our opinion, merge support is one of the strengths of the ClearCase product, however, once again Atria appears to have a less than complete understanding of merge support in C/CM.
C/CM has a type-based merge capability, which means that different object types can be merged differently. Moreover, with C/CM there is an important distinction between the merge support and the merge resolution tool. The merge algorithms for computing the common ancestors and synthesizing new versions to represent the merged results, are all part of the core C/CM product. The particular method that the user wants to use to resolve merge conflicts is easily configurable. This was designed to support third-party merge resolution tools such as those available from Frame, Microsoft, Sun, HP, and Intersolv.
In the upcoming 4.1 release, two forms of source file merge are provided. One is MergeAhead, which is an interactive, graphical merge resolution tool, and the other is C/ CM's new built-in automated merge. With the new release, on a case-by-case basis, the user can choose to perform an automated merge or an interactive merge. Also provided in the new release is improved support for directory merging.
5) View FlexibilityContinuus implements a static view model for working engineers, who must manually issue a command to see what's changed in a project. Because the view model is static -- and the licensing scheme reinforces the work-separated mode -- engineers may work outside of the change-control process for days or weeks at a time. Others on the project have no way of knowing what changes are in the works or their magnitude.
+ An engineer using ClearCase can choose to work in isolation from any changes made by other project members; or can work on "/main/LATEST" and be instantly exposed to the latest changes across a project or an organization. The engineer can change from one mode of working to the other in a matter of seconds, or can work in both modes at once in separate windows. The key is that ClearCase gives workers the flexibility to work in the way they need to.
Q: When an engineer has been working outside of Continuus/CM for several weeks, modifying dozens of files, and several of his teammates have been doing the same, how long does it take to reconfigure and resynch with all the changes?
Continuus responds: Once again, Atria chose to selectively misrepresent the capabilities of C/CM's work area (view) control. C/CM does provide controlled, insulated work areas by default. This is an extremely important capability for large project teams. However, contrary to the Atria implication above, C/CM also supports shared objects. The out-of-the-box model contains support for visible and public objects which are designed for those cases where groups of developers need to work very closely on related changes. As with ClearCase, C/CM users can switch from running insulated to running with latest changes at any time, or they can maintain multiple work areas.
Regarding the licensing scheme and running in "work-separated mode - engineers may work outside of the change-control process for days or weeks at a time...", Atria seems to have seriously confused two concepts. First, the insulated work area support most definitely allows a developer to work without fear of his work area getting corrupted, even for days or weeks at a time. We trust that ClearCase provides this most basic but critical SCM service as well. However, this in no way means that developers operate outside of the change-control process. Any change to the project objects in the work area involves interaction with C/CM, either through the C/CM graphical or command line interface, or by viewing or editing files in a work area that are actually controlled objects (protected by C/CM security). A license is automatically and transparently retrieved whenever a C/CM operation is performed. The license also will automatically and transparently release after the operation so that others may utilize that floating license.
The new 4.1 release includes remote development support which is also relevant to a discussion of view flexibility. For users running on laptop PC's or at satellite development locations, who do need to be able to work disconnected from the network and the CM repository, this industry leading technology does allow modification of project files disconnected from C/CM, but once reconnected invokes the reconcile operation which automates the synchronization of the replicated remote work area with the repository.
In summary, the C/CM view flexibility is every bit as powerful as what is provided by ClearCase, and the new support for remote work areas in release 4.1 extends the C/CM offering significantly further. Due to the C/CM architecture not requiring a proprietary file system, C/CM has much more flexible licensing than ClearCase, and this results in C/CM requiring less licenses for the same sized team than ClearCase. This would seem to be a clear advantage for Continuus users.
6) Rules for Choosing VersionsContinuus rules are strictly attribute comparisons. Their model lets you reselect the correct version for any file that was not properly chosen when the links were created. Once the links are created, changes to the parent are not seen until a manual reconfigure. The selection rules are buried in ACcent code that is very difficult to customize. Users can only control these limited attributes: release-name, platform, minimum state (to be picked up), and exclude states. The user has no way of knowing the logic that the product followed to pick up the versions for a project, often leading to confusion and unexpected results.
+ ClearCase rules are very powerful, rich, and easy to use. An individual can automatically see changes made in any line of descent or can isolate him/herself from changes as needed. Selections can be based on the ends of branches, on labeled versions, attributes, time-based restrictions, or any combinations of the above. Any file or set of files (by individual name or wildcards) can be controlled by the correct set of rules. A typical configuration will be chosen by an easy-to-understand set of 3 to 8 rules.
Q: How do I automatically see changes made to a particular line of descent?
Q: How do I choose the latest versions on a branch providing the version was not created after a date/time?
Q: If two branches were used to fix different bugs, and are not merged yet, how do I select one of the two for my project (other than manually)?
Continuus responds: There are several misrepresentations in the claims above, regarding how selection rules work, how they are customized, and how parameters are specified. With the C/CM product, the version selection rules, version control engine and the team's process model work together to provide the work area services. This is one of the fundamental differentiators between the C/CM and ClearCase products. If the customer is interested in supporting a simple, 2-state, check-in/check-out lifecycle model like SCCS, then ClearCase's simple selection rules may be sufficient. However, if the customer wants to address the parallel development needs (parallel releases, variant releases, parallel versions) of medium or large software teams, then a more sophisticated solution is required. To quote the recent Ovum report: "Complex lifecycles can be implemented with these ClearCase capabilities, but this can be a time-consuming, resource-consuming and error-prone way of implementing lifecycle support. Errors usually manifest themselves when users are denied access to an item under configuration control but cannot find the reason for the access denial."
The ClearCase customer can either try to build a process model on top of the basic ClearCase mechanisms, or they can buy C/CM which includes this model as a standard part of the product. The version selection rules are a key part of an advanced development model, and represent not 3-8 rules, but rather 50 or more. Requiring the user to specify these manually and individually may be fine for very simple and small teams, but is a very weak offering for the rest of us. With the C/CM product, the user simply selects choices from a dialog, and the parameterized selection rules then select the right versions, for the right platform, the right branch, for the right stage in the development cycle.
Contrary to the claims above, users can easily see why a version was or was not selected, or what versions would be selected if the work area is updated. To see changes automatically, use the shared object support discussed earlier. To use versions from branches with particular bug fixes, the parallel release support is designed precisely to make this a point and click operation.
7) Versioning DirectoriesContinuus automatically checks out the parent directory when a file is added to a project; but the user must remember to check the parent back in manually. Names of project files cannot be changed in a natural way -- a renamed file must be deleted and recreated, losing its past history. Directory merges artificially treat directories as if they were text files, resulting in cumbersome and error-prone manual workarounds. The merge process sees conflicts where there aren't any.
+ ClearCase handles directory versioning completely and correctly. Files and directories can be added, deleted, and renamed freely as the work requires. Directories can even be branched with differential contents for, e.g., different platform ports. Merges are parsimonious, accurate, and can be done automatically if no conflicts exist.
Q: Describe the reconciliation process after two developers have independently added files to the same directory.
Continuus responds: Regarding the statement that names of files can't be changed, but rather deleted and recreated, this is simply false (and has always been false). Any object can be renamed or moved through the move command. The history, relationships and metadata are all maintained.
Regarding directory merge, C/CM can link all objects that are checked out for a task (including directory objects) and provide a single operation to check in all modified objects, so the user does not have to keep track of the modified directory object manually as is implied. Also, the 4.1 release contains an all new directory merge feature, which utilizes the type-specific merge.
8) AuditingContinuus build auditing relies on a makedepend-style preprocessing of include files. This can fail in the presence of even simple #ifdef rules (for example, if the conditional logic depends on run-time or compile-time environment variables or switches).
+ ClearCase audits by monitoring the file system at build time. We know precisely which files are dependents regardless of the mechanism used to locate and read them.
Q: Is makedepend guaranteed accurate in the case of complex #ifdef logic with deep #include nesting?
Q: How do we find dependencies when make is used to do special kinds of builds that don't involve the cc compiler? For example, what if make invokes other tools such as Framemaker or scripts we have developed locally?
Continuus responds: C/CM's ObjectMake dependency generation does not suffer from the problems cited by Atria. Atria is correct that the generic public domain utility makedepend can have problems dealing with even fairly simple #ifdef constructs. However, arbitrary #ifdef logic and deeply nested #include files are the norm and not the exception.
ObjectMake uses the C/CM type system to support type-specific dependency generation. Methods are provided which handle most of the common object types (including C, C++ and over 60 other types), and the mechanism used can be easily customized for new object types, or even changed for existing object types.
By auditing builds at the file system level, there are certain cases which are very easy for ClearCase, and where we have to work harder than they to retrieve the same dependencies. However, in many of today's modern integrated development environments, especially in the Windows world, many dependencies are not on files, but rather on other types of objects (e.g. PowerBuilder, SQL Windows). Unlike the ClearCase product, the C/CM product is designed to handle these types of dependencies as well. Moreover, and perhaps most importantly, the C/CM dependency generation will run on operating systems which do not run ClearCase's file system, such as Windows 95.
9) Process ModelingThe process manual is 800+ pages. It is very difficult to modify any part of your process without buying consulting time.
+ ClearCase does not enforce any particular process model. Its tunable parameters can accommodate most day-to-day process requirements. You can evolve your process as your group grows and finds new requirements by attaching triggers to operations of interest, applying attributes or hyperlinks to files, and using the shell or programming language of your choice for more advanced processes.
Q: If we decide to modify our process after deploying the initial product, can we do it on our own? How long does it take to make changes? Can we see the language description and process modeling manual before purchasing?
Q: What happens when Continuus delivers a new version of the product? Do we have to re-apply all out customizations to the new process model? How do we know what has changed in the new model and how it affects our changes? Can you show us an example of how in the last release you documented the changes to your process model?
Q: Can we talk to some of your customers that have modified your base model to find out the skills and time required to do that?
Q: Can we talk to some customers who have applied process changes made in a prior release to a new release from Continuus?
Q: ISO-9000 and other standards require that we document and version control our process definition. Now that we can modify process parameters in the production databases, how are these changes recorded in the process model database?
Q: If we change the life cycle stages and associated promotions, how is that going to affect the functioning of the integrated Problem Tracking option? Do we have to modify that as well?
Continuus responds: The entire area of Process Management is one of the most significant differentiators between the two products. The ClearCase offering of rudimentary triggers and shell scripts is extremely weak, and the primary reason that Unix Review concluded that "Continuus/CM is a complete SCM solution, and ClearCase is most of one".
Moreover, Atria's analysis is considerably dated. C/CM still supports the industry's most powerful and complete process model, but as of nearly a year ago, the out-of-the-box model is now a highly-parameterized model, with many customizations as simple as filling out fields on a graphical form. Even very large customers run on the out-of-the-box model or something quite close to that.
With the parameterized process model, it is easy to customize our model by adding new types and customizing the behavior of new and existing types. For very specialized customizations, we do recommend using our consulting services organization because they can generally perform the customization in a small fraction of the time that a new user would take, and the customer can get into production that much faster. Note that the Ovum report recommends the same for advanced ClearCase customizations.
Continuus is pleased to provide references of large organizations running on the new process model. We acknowledge that prior to a year ago, the process model was not nearly as easy to customize. Our customers worked with us to improve this and we are very pleased with the results.
Regarding ISO-9000 and other standards, we believe it is very clear that Continuus is substantially better suited for organizations with these needs. Integrated process management is central to a well-defined, repeatable process. As to the implication that process changes to a production database are somehow lost or uncontrolled, this is also incorrect. A full audit trail of all process changes is created for each process change.
Regarding the question about changes to the process model affecting the integrated change management system, it is hard to imagine what Atria is alluding to. For most changes the process model, there would not be any impact on the integrated change management system at all. However, one can imagine process changes where the customer might want the particular change reflected in one or more screens or rules. If this were the case, the changes to the change management system would be very simple.
Since Atria brought up integrated problem tracking and change management in general, this is another area where Atria is significantly weaker. In order to fill this hole, Atria recently purchased a simple defect tracking system from Silicon Graphics, and is now trying to graft this on to ClearCase. In contrast, the Change Management system in C/ CM is an integral part of the product, built on the same repository, using the same object system, with core level support for the relationships between change requests, tasks and the associated changes to source code, tests and documents.
10) Support of Multiple SitesThe Distributed Code Management facility is simply an export/import facility that only deals with complete versions of all files selected. It has no knowledge of what has changes since the last export, so it makes a complete physical copy of all files. This can be very time-consuming when transferring data over a network. DCM deals only with file data and does not move attributes and labels, losing all metadata in the transfer.
+ ClearCase MultiSite automatically captures, transmits, and synchronizes both file data and metadata. It also deals only with incremental changes (just the changes to files that have been modified), and fully automates the store and forward functions (which are manual in Continuus).
Q: If I fix Bug 888 at site B and then move the change to site A, how does site A know that those changes fixed Bug 888?
Q: How many scripts will I have to write to automate the capturing and transmitting of changes between sites? Can I transmit only changed files, or must it be the whole set? How do I automatically select the changed files?
Continuus responds: Atria is confusing several different facilities offered by Continuus. First, C/CM does have an import/export facility, but it has little to do with support of multiple sites. The import/export facility is an administrative utility for transferring objects from repository to repository (including full meta-data). There are two technologies for supporting multi-site development, each designed for different project team structures. The Distributed Code Management (DCM) service is designed for distributed development in multiple physical locations, where all or part of the repository is to be replicated, and where some of the sites may not be running Continuus/CM.
The 4.1 release introduces the new Remote Development service, designed for satellite development locations or for portable systems which may be disconnected at times, but where all locations have at least intermittent connectivity to the Internet. The Remote Development support provides repository replication on the project basis, and is incremental, meaning that it only sends differences between sites. Special software is included that reconciles differences between local sites and the repository.
Both services are designed for different purposes, and obviously have different trade-offs. Based on our analysis, Atria's MultiSite has some very significant limitations such as locking branches down to single sites (so much for parallel development!), requiring that all sites run MultiSite, and not being included in the core product.
We believe that the combination of our offerings provides the most powerful and comprehensive support for today's distributed development organizations.
The following questions were posed, probably rhetorically, in a follow-on Atria sales message. Several of them have been addressed earlier, but a few are new.
Q. Given that today Continuus reported to Dun and Bradstreet operating losses for the quarter ending September 30, 1995. I thought you might want to consider the following questions...
A. Continuus Software Corporation is a privately-held company and as such does not provide public financial statements. Similarly, we do not report our financial results to Dun & Bradstreet or any other similar organization. We do, however, believe Continuus Software will one day become publicly traded. Consequently, we maintain Continuus' financial records according to public company standards and are audited by Deloitte & Touche. Currently, the company is intentionally investing in resources that can accommodate its rapid growth.
At Continuus we understand how important a company's financial prospects are to customers making a long-term investment in our software. In that spirit, the facts about our company's performance are:
In sum, Continuus' financial profile is typical of venture-funded, pre-public companies at our current stage of growth. This year we have posted record monthly and quarterly revenues. We are also using this growth and our venture funding to invest in increasing sales capacity and building up a marketing organization to take advantage of increasing demand for change management software.
Customers and prospects who desire closer examination of the company are invited to contact Continuus' management or representatives directly; to visit our headquarters and see our software in use by our own development teams; meet our development, service and support personnel; and to get more detailed financial information on a non-disclosure basis.
Q. Please comment on your use of SCCS as the version-control engine. Why do you stick with 15-year-old technology at the very core of your SCM system? Why do you use even this technology so inefficiently?
A. See above as to why this statement is incorrect.
Q. Your customers cannot effectively modify your out-of-the-box process, but must employ your consulting services for even the simplest changes. How much does it cost an organization over time as their processes evolve and mature?
A. If the customer wants a process model at all, the choice is actually between buying Continuus which includes a parameterized model, or writing an entire process model on top of the simplistic ClearCase mechanisms. The new C/CM parameterized model is easily customizable for the most common customizations. So no matter how it is measured, the investment needed to develop and maintain a process model based on Continuus is dramatically less than one based on ClearCase.
Q. How can you equate DCM to Atria's ClearCase MultiSite when it provides even less functionality, and requires more more manual intervention, than ClearCase version 1.0 did in 1992 (before MultiSite existed) to achieve similar results?
A. See above.
Q. Your developer customers spend 50% of their time working entirely outside the control of Continuus/CM, according to the way you license and sell the product. How can this help to ensure a robust and secure devvelopment process?
A. C/CM users spend approximately 50% doing C/CM operations, but closer to 100% of the time working on C/CM controlled objects. Very big difference. With ClearCase's architecture, you need a license even though you are not necessarily performing an SCM operation. With C/CM's industry-leading process support, we do much more to ensure a robust and secure development process than ClearCase, even compared to those ClearCase customers that have written literally thousands of lines of shell scripts on top of the ClearCase commands.
Q. Please comment on the ramifications of the fact that a "branch" is not a first-class object in your system. Surely this leads to database inefficiencies and to uncertainty for the developer as to who else may be working on the same modules. Why do you forego even the support for branches that raw SCCS offers, at a cost in storage and performance?
A. As described above, a branch is a first class object. We forego support for the 15 year old SCCS technology because we offer a much more powerful, flexible and easier to use version control engine.
Q. How can this weak branch infrastructure, combined with the limitations and inaccuracies of Atherton's MergeAhead tool, possibly support parallel development in a real-world team environment?
A. With a couple of button clicks a C/CM administrator can allow or disallow parallel check-out and parallel check-in for individual types. We notify users of parallel versions on check-out, check-in and reconfigure, and support merge at the time of check-in, or at the user's discretion from the graphical history view or the command line. The user can select either automated or interactive conflict resolution. The MergeAhead tool automatically uses the common ancestor to correctly suggest changes, and the user can easily view and select from the changes, or accept the suggested changes.
C/CM provides out-of-the-box support for all three forms of parallel development: parallel releases, parallel versions, and variant releases.
Q. A user in any role can check in a file to a different state than that specified by the defined process. A developer can "modify history" after merging changes from parallel versions, rendering it impossible to determine a common ancestor. How can your customers maintain a robust and secure development environment with all the ways developers can "back-door" the process?
A. Again, this is incorrect. Only the administrator (C/CM superuser) can circumvent the process and security rules. It is ironic to even hear this sort of misrepresentation from a vendor that encourages process support via Unix shell scripts.
Q. You make extensive use of symbolic links to achieve a kind of file-system transparency. Won't this technique run up against file-system constraints, such as a limit on the number of Inodes, for large development projects?
A. File system projections can be across any number of file systems on any number of computers. Even a 15 million line single project runs with a standard file system configuration.
Q. Isn't it true that Continuus/CM's minimal set of version-selection rules leaves the user unable to determine exactly which files will be presented? It seems that developers would typically need to do a great deal of error-prone manual selecting after every reconfigure.
A. No, actually our selection techniques are much simpler and more straightforward than Atria's. Our users don't have to know how to write selection rules or complicated configuration specs, or remember what they named a branch. They simply select a value from a list in a dialog. (Most of the time the reconfigure attributes are correctly set automatically.) And if they want to know why certain versions were selected, they can click a button to get the details.
Q. Isn't Continuus/CM's build support essentially limited to Sun make compatibility, even on other platforms? What about customers who make extensive use of advanced gnumake features?
A. C/CM's ObjectMake supports both Sun make and, as of the 4.1 release, Microsoft's NMAKE formats, in addition to most features found in Gnu make, HP make and IBM's AIX make. Furthermore, C/CM supports the user running his own make.
Q. Your build support relies on a makedepend-like tool. What about customers who work in languages other than C/C++? Makedepend can be confused even by simple #if branching logic; what help do you provide for customers whose makefiles are other than rudimentary?
A. See above.
We hope that this document has helped to clarify the issues raised by the Atria sales staff.
At Continuus, we feel that each vendor in the SCM market brings a different approach to solving SCM problems. The focus should be on which product and company best fits the requirements of your organization.
Continuus welcomes all inquiries from prospective customers, and we will be pleased to demonstrate all statements made about Continuus/CM in this document. Anyone who would like either product documentation, technical white papers, or an on-site demonstration is encouraged to call their local Continuus sales office, or our US headquarters at 1-800-820-1995 or our European headquarters at 44 1 344 382 118.